Digital content distribution is widely used to distribute software, data, and documents where the origin and authenticity of the data is an important consideration for the receiving party. Rights management (RM) and enforcement is highly desirable in connection with digital content such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content is to be distributed to one or more users. Digital content could be static, such as a text document, for example, or it could be streamed, such as the streamed audio/video of a live event. Typical modes of distribution include tangible devices such as a magnetic (floppy) disk, a magnetic tape, an optical (compact) disk (CD), etc., and intangible media such as an electronic bulletin board, an electronic network, the Internet, etc. Upon being received by the user, such user renders the digital content with the aid of appropriate rendering software such as an audio player, a text displayer, etc. on a personal computer or other hardware.
In one scenario, a digital content owner wishes to distribute digital content to many users or recipients in a form allowing the recipient to assess the origin and validity of the content. In such a scenario, the content may be computer software or data. The content owner or publisher derives value from the use of its products, but the recipients may be reluctant to use it without proof of its origin and integrity.
In another scenario, a content owner or rights-owner such as an author, a publisher, a broadcaster, etc., wishes to distribute such digital content to each of many users or recipients in exchange for a license fee or some other consideration. In such scenario, then, the content may be an audio recording, a multimedia presentation, etc., and the purpose of the distribution is to generate the license fee. Such content owner, given the choice, would likely wish to restrict what the user can do with such distributed digital content. To do this, they need to target a rendering device, or software application, that will enforce the desired restrictions. This requires the ability to generate a content license which: 1) identifies the content; 2) describes the desired use restrictions; and 3) allows the rendering device or software to validate the license as coming from an authorized content owner.
The second scenario can be extended in a straightforward manner to encompass a content developer, such as an employee in or member of an organization, that wishes to distribute such digital content to one or more other employees or members in the organization or to other individuals outside the organization. Here, the distribution of the content is more akin to organization-based content sharing in a confidential or restricted manner, as opposed to broad-based distribution in exchange for a license fee or some other consideration.
In such extended second scenario, then, the content may be a document presentation, spreadsheet, database, email, or the like, such as may be exchanged within an office setting, and the content developer may wish to ensure that the content stays within the organization or office setting and is not rendered by non-authorized individuals, such as for example competitors or adversaries. Again, such content developer wishes to restrict what a recipient can do with such distributed digital content. As before, this requires the ability to generate a content license which: 1) identifies the content; 2) describes the desired use restrictions; and 3) allows the rendering device or software to validate the license as coming from an authorized content owner.
As described in the preceding scenarios, publication of digital content is likely to include digitally signing the content to produce a digital signature that can be employed to validate the content's owner and its integrity at some later point. Publication of such content may in addition or in the alternative include issuing a publishing license and/or use license or the like for the content and digitally signing the issued license to produce a digital signature for similar purposes. In either situation, and as is known, authority to digitally sign may be granted from a higher authority to the publisher or licensor by way of issuance of a digital certificate from the higher authority, where the digital certificate includes a public-private cryptographic key pair, and where the digital signature is based on the private key and validated based on the public key.
Thus, the publisher or licensor attaches to the digital signature the digital certificate, and perhaps a chain of certificates leading back to a root trust authority that is known to an entity that would validate the digital signature. In particular, the entity would be in possession of a public key of the root trust authority and would employ same to validate a digital signature of a first ‘root’ certificate in the chain. Assuming the signature of the root certificate does indeed validate, a public key in the root certificate would be employed to validate the signature of the next certificate in the chain, and so on until the signature of the last certificate in the chain is validated and the public key therein is then employed to validate the digital signature of the content or license.
In the prior art, in the situation where a digital certificate is employed to publish content, an issue exists in that the digital certificate and the private key and signature thereof have an expiration after which such certificate and private key and signature thereof are not guaranteed by the issuer. For example, in the case of an X.509 digital certificate, a date is specified in the certificate after which the signature, the private key, and the certificate expires. Reasons for such an expiration are many and varied, but typically are based on the fact that the issuer of the certificate is not required to guarantee the certificate after the expiration thereof, and accordingly is not responsible for performing ministerial tasks with regard to the certificate, such as possible revocation if need be. At any rate, an expired certificate from an issuer usually is replaced by a newer certificate from the issuer, likely as part of a retail transaction where the issuer receives some sort of remuneration for the newer certificate.
Thus, from the point of view of the issuer of a certificate, an issued certificate should expire after a relatively short period of time, both to lessen the liability of the issuer and to provider the issuer with an amount of revenue from issuing a newer certificate. However, from the point of view of a publisher of digital content using such a certificate to digitally sign the content, the certificate should remain valid for an extended period of time, if in fact the certificate expires at all, especially inasmuch as an expired certificate typically cannot be employed to validate and render content in an RM system. Of course, based on the tension between such two opposing points of view, a digital certificate usually expires in some period of time on the order of six months to two or three years.
Nevertheless, even such a period of time is oftentimes not long enough for the consumer of the content. For example, commercial software distributed over the Internet may have value to customers for five years or more. For digital content such as a musical recording, with a license that provides for use of the content in perpetuity, the consumer would not wish to have the usefulness of such license diminished because the license or the content is validated based on a digital certificate that expires after a year or two.
To alleviate such a situation, and in the prior art, a work-around solution has been developed whereby use of a certificate that expires also requires an additional signature based on another root trust authority, where the additional signature is based on a digital certificate from the another root trust authority that never expires. However, doing so requires that the another root trust authority assume the aforementioned liabilities of guaranteeing the certificate in perpetuity and performing ministerial tasks with regard to the certificate in perpetuity. As may be appreciated, such liabilities can be quite burdensome and should be avoided if at all possible. In addition, such a root authority becomes a single point of failure whose compromise would prevent validation of digital signatures on very large bodies of content potentially from multiple owners or publishers.
Accordingly, a need exists for a long-life digital certificate for long-life digital content or the like, whereby the certificate can be employed to validate the content for a relatively long period of time, but where the liabilities and costs associated with issuing the certificate and maintaining information on its validity are mitigated. In particular, a need exists for such a certificate where the time during which a signature based on the certificate may be created, and hence the associated private key used, is separated out from the expiration of the certificate. More particularly, a need exists for such a certificate where the validity of the certificate and ability to use same to validate a digital signature has a relatively longer life span, while the time during which a digital signature may be created, and hence the private key used, has a relatively shorter life span. In addition, there are many instances where one would like to provide specific restrictions within the certificate governing what types of content may be signed. Thus, even though the certificate and the private key thereof may be employed in the creation of digital signatures only for the relatively shorter life span, the digital signature provided based on such certificate may be validated for the relatively larger life span.